當我們談論 Specification by Example（SBE）時，最重要的並不只是「寫出幾個範例」，而是透過討論範例來釐清需求、促進共識、避免誤解。這種方式的成功關鍵，在於「誰來參與討論」。這篇文章將介紹五種 SBE 討論時常見的人員組合方式，並說明其適用階段、優點與注意事項，讓團隊能根據情境選擇最合適的方式。
範例不是單一人的想像，而是來自不同視角的交集。產品經理知道商業邏輯，RD 知道系統限制，QA 想到邊界條件與異常情境，業務代表則能還原真實場景。這些不同的背景混合在一起，才能讓範例「更接近真實」，測試「更能捕捉問題」，而不是紙上談兵。
• 適用階段：專案剛啟動、對整體需求一無所知時
• 做法：召集開發、測試、業務等全員，參加大型說明與範例討論
• 優點：
o 可快速讓所有人對業務有初步了解
o 技術與業務可以同步激盪思考
• 注意事項：
o 不易安排時段，召集成本高
o 若未控管好，容易流於漫談
例子：在新的「訂票系統重構案」初期，召集 20 位跨部門人員開會，共同產生範例，例如「使用早鳥票訂購後取消是否收手續費？」這類敏感規則。
• 適用階段：需求已知，但細節尚未釐清
• 做法：由 RD、QA、分析師組成小型小組進行集中討論
• 優點：
o 成員少，溝通快
o 適合釐清一個特定模組或問題
• 注意事項：
o 須確保三人對同一領域有一定了解
o 結論需回傳團隊，避免資訊落差
例子：當發現「退票政策」模糊不清，三劍客聚在一起討論各種退票情境：超過 30 天退票、臨時取消、延誤導致退票等，逐一範例化，避免誤解。
• 適用階段：分析師可提供正確行為，RD知道撰寫測試的最佳方式，這樣就可以協作編寫
• 做法：分析師或產品人員與 RD（或 QA）一起編寫測試用例
• 優點：
o 避免資訊轉述錯誤
o 可直接思考「這樣設計，怎麼測？」
• 注意事項：
o 若沒有業務背景的人參與，仍可能漏掉使用者角度
例子：分析師提供規則「白金會員超過 2000 元可免運」，RD 協助轉為 Gherkin 格式：
Given 使用者為白金會員
When 購物車總額達 2200 元
Then 結帳頁面應顯示免運費
• 適用階段：即將交付開發前，需要確認需求充分
• 做法：由經驗豐富的 RD 主動審查需求說明
• 優點：
o 可提早發現需求模糊處
o 減少日後返工
• 注意事項：
o RD 需投入時間閱讀需求，適用於高複雜任務
o 須避免 RD 只是「被動簽核」
例子：某 RD 在審查「改名流程」需求時，發現系統中已有姓名驗證機制，主動提出邊界狀況如「改名後重複帳號怎麼處理？」。
• 適用階段：任意時刻，特別是在敏捷團隊中常態化運作時
• 做法：團隊與業務人員就坐在一起，隨時可聊
• 優點：
o 有彈性，適合即時釐清小問題
o 增加彼此熟悉與信任
• 注意事項：
o 記得回收口語討論的共識，記錄在案
o 不可完全取代正式需求討論
例子：一位 QA 在寫測試時不確定「錯誤帳號登入三次要鎖多久」，直接問隔壁的 PM，30 秒搞定，並補充成範例文件。
進一步比較解析與應用建議
(1) 參與人數與互動深度
• 「大型全體工作坊」互動密度低但廣，適合建立初始共識。
• 「神勇三劍客」與「結對編寫」屬於高密度深討，適合挖掘複雜規則。
• 「非正式交談」彈性高，互動自然，但需留意知識沉澱。
(2) 資訊透明 vs 成本平衡
• 大型工作坊資訊最透明，但成本與時間代價也最大。
• 「神勇三劍客」與「RD 審查」在時間與效率上取得平衡。
(3) 範例品質與可測性
• 「結對編寫」容易產出可落地的驗收範例（如 Given-When-Then）。
• 「非正式交談」則可能只是口頭確認，需搭配後續記錄或 refinement。
(4) 團隊文化與成熟度對應
• 若團隊不習慣討論需求，建議從「神勇三劍客」或「RD 審查」開始。
• 成熟團隊可鼓勵「非正式交談」與「結對編寫」常態化。
組合策略建議
• 啟動期：大型全體工作坊 → 建立背景認知 + 初步範例
• 需求釐清期：神勇三劍客 → 深入挖掘案例細節
• 實作前：結對編寫 + RD 審查 → 實作與測試準備
• 日常補洞：非正式交談 → 補足臨時疑問與資訊缺口
🧭 結語：選對人組合，比討論技巧更重要
進行 SBE 不只是寫例子，而是找對人、在對的時機做對的討論。你可以從「全體說明 → 小組釐清 → 結對寫作 → RD 審查 → 平時交談」這樣的流程中逐步導入範例思維，根據階段與人力彈性調整。
當大家開始以例子說話，而不是只講抽象需求，你會發現，很多錯誤其實是因為沒問對問題、沒拉對人。
iThome鐵人賽
看影片追技術